I disagree with this fix. The bug is inside std.conv. This should work:

to!int(E3.C);

What you are doing is just a bypass to avoid a call that is buggy, but the problem persists. Given a type T that is an intgral (or at least, validates isIntegral!T), then I think to!int(T.init) must pass.

I've edited the title. It's nice to have a short description in the title, otherwise the notification page is not very useful when it only lists Issue numbers.

@monarchdodra You're right, to!int(ulong) should work. It just might throw a range error at runtime, but that should be a runtime error, not a compile error. I'll look into fixing that.

Hmm, the bug is that isIntegral returns true for a ulong enum, but std.conv.to explicitly excludes enums from narrowing conversions.

Why are enums excluded from narrowing conversions? Should std.conv.to allow narrowing conversions from integral enums to integral types?

Also, does it make sense to pass an enum as a field width? It would seem to me that it should be rejected, so getNthInt should really check for isIntegral!T && !is(T == enum).

Hmm, on second thoughts, it's conceivable that somebody might want to use an enum for enumerating a fixed set of field widths to use (e.g. enum Widths { narrow=2, normal=5, wide=10 }, so I guess getNthInt should permit that.

So it's really just std.conv.to that needs to be fixed to allow narrowing conversions of integral enums to integral types. (My other pull addresses the other issue of converting from integral types to enum.)

OK, reworked the fix to allow narrowing enum -> integral conversions by std.conv.to.

std.format.getNthInt now remains untouched, std.format just gets a new unittest to prevent regression on issue 6893.